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2. hereby declare :- 
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This iovention relates to a method and apparatus for version ing and. 

! . * ■ ' 

V- . - 

configuration management of models. 

• - ' - . 

The software industry is gradually moving to a new paradigm of 
development, where modeling is moving from being just an 
analysis/design aid to being a more pervasive end-to-end system 
development tool. This new paradigm views modeling and coding on 
a continuum, with more and more things being pushed from the 
domain of coding to the domun of modeling. This shift is bemg 
facilitated by the emergence of various modeling standards like 
Unified Modeling Langttage(UML). Meta Object Facility(MOF). 
Extended Markup Langu^e(XMLX etc., with active ongoing efforts 
to make them ever more semantically richer. 



When modeling takes over the space of coding, it will have to 
contend with the problems of size, chmge and variation just as coding 



partitioned into modules or components with well-defined interfaces. 
As the information system evolves, its models also evolve. A 
successful information system typically has many variants specific to 
various delivery platforms, geographical regions, and multiple 
development streams. Versionmg is a natural consequence of 
evolution and variation. Witfiout adequate tool support, tiie problem 
of versioning mid con^guration man^ement can quickly get out of 
control. 
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2. State of the art 



In the coding world, there exist several versioning and configuration 
managementtools like sees. CVS. VSS. etc. that help in managing 
these problems. However, these tools are not snitable for the 
modeling world as they are based on flat files. They treat files as lines 
of text and do not understand the semantic entities and their 
relationships contained in the files. 

On the other hand, in the modeling world, there exist some repository 
systemsthatprovidesupportfor versioning of models to some extent. 
However, these do not go fm^ enough as the versioning model 
supported by them largely mimics the file-system model, in that they 
treat the system as a set of objects that cm, be versioned. without 
paying much attention to the relationships between the objects. Users 
are responsible for assembling related objects into meaningful 
configurations. There is no support for addressing questions like: 

Is the configuration complete? 

Does it have all the required objects? 

Are the objects compatible with each other? 

Such a sohition does not scale up to the demands of large software 
systems, as it is extremely difficult for us^s to manually assemble 
large numbers compatible objects mto conftgurations that are 
complete. 



This inventioD envisages a versiooing and configuration management 
method and apparatus tiierefor that addresses the above issues by 
exploiting the relationships captured in die models. 

The method and apparatus therefor is especially well suited to 
generic, extensible model-repository systems that are meta-model 
driven. 

A modeling framework (mappable to M OF) for generic, extensible 
repository systems is ilhistrated in Figure 1 of the accompanying 
drawings. 

The meta model shown m figure 1 is the base model. It is the schema 
for modeling meta models. The meta meta model is capable of 
describing itself, i.e., it can model itself. It is the root of the 

instantiation hierarchy. The meta meta model consists of objects, 

associatio.ns-an.d-PTfl.pjerti^^ 

accompanying drawings. 

In this specification a meta model is an mstance of the meta meta 
model It consists of Meta Objects with associated Meta Properties, 
and Meta Associations defmed between Meta Objects. A meta model 

I 

defmes the structure md semantics for the infonnttion system model 
(e.g.: UML meta model). 

Information system model or User model 

The information system model, also referred to as the user model, is 
an instance of a meta model. It ci^tures the description of the 
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information system from varioos points of view as specified by the 
metamodel (e.g.: UML model of abanking system). 

The above modeling framework is abstract enough to be able to 
support modeling method and apparatus therefors like UML, ER, and 
the like. * 

The versionmg and Configuration Mansigementmediod and apparatus 
envisaged in accordance with this mveotion can be described as 
follows: 

A versionmg and configuration management system for managing 
models that are compliant with the above modeling framework is 
shown in Figure 2 of the accompanying drawings. In the model, 
'object' refers to an element instance of either the user or the meta 
model. The model shown m the figure 2 con come as a pre-defmed 
m eta-model in the repository. 

Component 

Component is a construct for partitioning an information system 
model. Each module of an mfonnation system can be mi^ped to one 
or more components. The model for each module can dien be placed 
in its components. A component is a container for model elements 
like objects, properties and associations. An object on its o-eation is 
placed in a component and carries the identity of the component. 
Versioning of models is done at tiie level of a component. A 
component is realized by its versions. The first version of a 
component is created when the component is created. All other 
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versions are derived* directly or i&directty» from the first version. 
Versions of compatible components are assembled, within a 
configuration, to represent the complete model of an mformation 

system.. .. — : - - 

An object belongs to a component and is ^versioned with die 
component. Thus, an object gets the version number of its container 
component, but two versions of an object will always have the same 
Objectld. When an object is contamed m a component version, its 
properties and the associations owned by it are also contained in that 
component version. 

Component is a typeless construct in that an mstmice of any meta 
object can be placed m a component Versioning is implemented at 
the component level and not at the object level l^canse an object by 
itself is usually too fme-gratned an entity for versioning. An object m 



Components provide a mechanism for grouping objects for the 
purpose of versioning; grouping can be done at my required level of 
granularity. 

Associations can either be mtra-componrat or inter-component An 
association between objects belonging to different component 
versions is an inter-component association. An inter-component 
association establishes a relationship between two component 
versions and it belongs to the component version to which the owner 
object of the association belongs. Inter-component associations can 
exist only in the context of a conf^uration. 









J m 
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A component version guarantees chaage isolation. Changes made to 
the objects in a component version are not visible in other versions of 
the component or other components. Conceptually, anew version of a 
component contains copies of the objects of the version from which it 
is derived. A component enables concnnrent development of different 
parts of the model A component version can be shared between 
various configurations. 

Figure 3 of the accompanying drawings diows two conf^urations of 
the method and apparatus of this invention in its operative 
configuration. (Banking Application Analysis and Design), versions 
of components (Business Partner mid Accounts) and objects 
(Customer, Account, Balance, etc.). Two versions of Account object 
can be seen. The first venioo in the Analysis Configoralion has 
associations with two Attributes: Accid and Balance. The second 
version of the Account object m the Design Configuration has 
associations with an Operation (Withdraw) and a Table (AccTbl) in 
addition to having associations wtdi the Attributes. 

The version management facility provides support for tracking the 
history of changes to the components, branch versioning, selection of 
difTerent versions of different components to form a meaningful 
configuration, and *difT and merge' of models contained in different 
versions of components. 

Configuration 

A configuration is a container for assembling different versions of 
components. A configuration represents the notion of 'a complete unit 



of woilc'; it can be seen as a product; as an input to a set of code 
generation tools, or as an inpnt to a 'make' utility. A configuration is 
a complete set of compatible components and provides the context for 
creating relationships between various components via the inter- 
component associations. Only one version of a given component can 
belong to a configaration. A configaration can contain odier 
configurations. Since a configuration is defmed as an independent and 
complete entity, a container configuration can 'use* or 'depend on' 
the contained configuration but not vice versa. 

A configuration is realized tiirough its versions. Unlike component 
versions, two versions of a configuration can overlap, i.e. they can 
share component versions. For example, in figure 3, the component 
version 'Business Partner Module Vl.O' is shared by the analysis and 
design configurations. The versioning of configurations is provided 
for the purpose of tracking the version history only. Thus, 




component versions are designed to support change isolation. 



Completeness of a Configuration 

The "ownership" property of associations helps defme and enforce 
the notion of completeness of a configuration with regard to the 
component versions it contains. The inter-component associations in 
a configuration est^lish ^consumer-supplier* relations between 
component versions. A component version that owns an inter- 
component association depends on the associated component version. 
The owner object (and hence its container component) of such an 
association is deemed 'incomplete' without the associated object (and 
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hence its container component). Thns^ a configuration is complete 
only if it contains a complete set of related component versions that 
satisfy all the *owoed* inter-component associations wiUiin the 
context of the configuration. This notion of completeness is enforced 
for all configurations ensuring that all the 'consnmer-supplier* 
relations are satisfied when components are assembled into a 
configuration. 

Figure 4 of the accompanying drawings shows examples of complete 
and incomplete configurations. The 'owned' association 'Uses' of 
Class Customer is not satisfied in conflgoratioii A, hence making it 
incomplete. 

Compatibility of components 

Inter-component associations provide a mechanism to establish and 
enforce compatibility semantics between two component versions. A 
version of an object can replace another version of Uie object in an 
association. Hence, two versions of an object are deemed compatible. 
An object is shared if its component version is shared m more tiian 
one configuration. Such a shared object must Appear the same, with 
respect to its properties and owned-associations in all the sharing 
configurations. Changes made to a shared object within a 
configuration must be reflectable in all the sharing configurations. 
Specifically, addition and deletion of owned-associations to a shared 
object should be possible in all the sharing configurations. The 
configuration A in figure 4 shows an invalid sharing condition for 
class 'Customer' in tiie shared component 'Business Partner Vl.O'. A 
set of component versions are deemed compatible if they can be put 



together in a configuration without causbg any riiaring condition 
violation with respect to inter-component associations. These notions 
of sharing and compatibility are alwiqrs enforced by the system. 



The notion of component compatibility is based on the premise that 
two versions of an object are compatible with each otfier. This notion 
|)f compatibility is designed to allow maximum possible flexibility in 
Component composition by enforcing only die minimum required 
constraints. 

Di£f and Merge 

Quite often, a component needs to be developed concurrently by 
independent teams in a non-interfermg w^. This can be achieved by 
deriving a branch version of the component. At the end of the 
development effort, the branch version of the model needs to be 
merged back into the main stream. 

A facility needs to be provided to compare ('DifT) and merge models 
contained in two component versions or two configurations. The 
*Difr operation can be done at the level of configurations, component 

versions, or objects. 

Two versions of mi object are compared based on their Object Ids and 
m terms of their property values and associations. OHen, comparison 
of two objects by themselves is not of much value unless it is done in 
the context of its associated objects. Such a context is also necessary 
while merging versions of an object. In general, in a given model, 
some objects play the role of primary objects and others play the role 
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/ 9 of companion objects. For example, in the 00 model. Class is a 

primary object and Data Member is a companion object. Two Data 
Members should only be compared in die context of die Classes to 
which they belong. Such context sensitive comparison and merge 
operations can be performed by specifymg object-association graphs 
or patterns. An example pattern for comparing classes in two 
components could be: 'Class-HasData-DataMember', 'Class- 
HasMethod-Method*. It is also possible to specify die list of 
properties to be compared. In addition to providing a context, a 
pattern also lim its the scope of comparison to models of interest. 

Advantages of the method and apparatus envisaged in accordance 
with Uiis invention inchide the following among others: 

1. Association 'ownership' property can model notions like 'client- 
supplier relation ship*, 'depends on*, 'can not exist widiout', etc.. and 
provides die basis for relationship driven configuration management. 

2. Componentprovidesabetterhandleoverdiegranularity ofdieunitof 
versioning. 'Object' is too fme-grained an entity for version tracking. 
A component allows related objects to be put together in a container 
and treat that as the unit of versioning. This solution scales up better 
tiian object versioning. 

3. Component versioning provides change isolation. Configurations 
provide controlled sharing, by enforcing sharing semantics. 
Controlled sharing avoids the need for frequent merges, which are 
error prone. If required, traditional check -out/check -in model of 
versioning can be easily simulated using components and 
configurations. 
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4. The properties of 'confignrfltion completeness' and 'component 
compatibility* greatly help in composing configurations correctly. 

5. Pattern-based 'difCteerge* feature facilitates in conducting intelligent, 
structure-driven comparison and merge operations. These operations 
can be performed at various levels: object, component version or 
configuration. 



Although the invention has been described in terms of 
particular embodiments and qiplications, one of ordinary skill 
in the art, in light of this teaching, can generate additional 
embodiments and modifications without departing from the 
spirit of or exceeding die scope of the invention. Accordmgly, 
it is to be understood that the drawings and descriptions herein 
are proffered by way of example to facilitate comprehension of 
the invention and should not be construed to limit the scope 
thereof. 




Dated this 16^ day of July 2001 




)ewan 
Of R. K. Dewan & Co., 
Applicants' Patent Attorney 



12 



/ TATA CONSULTA>JCV SERVICES 

'NAME : (TATA SONS LIMITED) NO. OF SHEETS :5 

NO. /MUM/ 01 SHEET NO. : 1 

PROVISIONAL SPECIFICATION 



Level 1 



Level 2 



Level 3 



hstanceof 



/ ^ hstance of 



hstanceof 



^Wormalon system or ustr^twki m 



FIGURE - 1 




DR. MOHAN DEWAN 
APPLICANT'S PATENT ATTORNEY 



1 7 JUL 2001 



/ i^/-iavijUf .^xr^ir^ ov-^i^ij ^i&vu. x i^L^y ^i^vy. 01 xi^i^ 1 ij . ^ 

/ NO. : /MUM/ 01 SHEET NO. :2 

PROVISIONAL SPECIFICATION 




FIGURE - 2 




DR. MOHAN DEWAN 
APPLICANT'S PATENT ATTORNEY 

1 7 JUL 2001 




/ TAxAcONGULtANCV SERVICES 

N'AME .(TATA SONS LIMITED) NO. OF SHEETS : 5 

NO. /MUM/ 01 SHEET NO. :3 

PROVISIONAL SPECIFICATION 




FIGURE - 3 



DR. MOHAN DEWAN 

- APPLICANT'S PATENT ATTOR>fEY 

JtiL 20,01 ■ 



1N/\1VLP OWiNO JLrliyH 1 CL/y 

NO. : /MUM/01 



SHEET NO. : 4 




^ 7 JUL 200^ 



DR. MOHAN DEWAN 
APPLICANT'S PATENT ATTORNEY 



TATA cowsu i_T/4 wcy s V ic es 

•NAME :CrATA SONS LIMITEQ) 
NO. /MUM/01 



NO. OF SHEETS :5 
SHEET NO. : 5 



PROVISIONAL SPECIFICATION 



Objects in Mcta Mcta 
Model 


Properties of Object 


MelaObject 


Nome. Description, AbstractConccite 


MetaProperty 


DalaTypc Ciiar, Number, Binary 
Si/c " Size of Char String and Number 


MetaAssociation 


Forward and Reverse Name 

Source and Destination Optionality = Association is optional or mandatory 

for source or destination object 

Source and Destination Cardinality = One or Many 

Owner of the Association « Source or destination objcrt is llie owner of 

the association 



Associations in Meta Mcta Model 


Properties of Association 


MetaObject InheritsFrom MetaObject 


A MetaObject inherits associations and properties from 
another MelaObject. 
Many to Many; Optional 


MetaObject Has MetaProperty 


MelaObject has MetaProperties. 
One to Many; Optional 


MetaObject SourceOf MetaAssociation 


MetaObject is source of a MetaAssociation. 
One to Many; Mandatory for MetaAssociation 


MetaObject DcslinationOf MetaAssociation 


MetaObject is destination of a MetaAssociation, 
One to Many; Mandatory for MetaAssociation 



FIGURE - 5 
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